glarea: Update documentation

Drop the fixed pipeline example code.

https://bugzilla.gnome.org/show_bug.cgi?id=744394

glarea: Clean up the header

docs: Add missing GdkGLContext symbols

gl: Drop profile for gdk_window_create_gl_context()

Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.

gtk: x: fix compilation without x11 backend

https://bugzilla.gnome.org/show_bug.cgi?id=744148

main: Make gtk_get_option_group() available to bindings

Now that GOptionGroup is registered as a boxed type [1], don't skip it
in gobject-introspection.

[1]: See https://bugzilla.gnome.org/show_bug.cgi?id=743349

https://bugzilla.gnome.org/show_bug.cgi?id=743350

gtklistbox: add bind_model()

gtk_list_box_bind_model() binds a GListModel to a GtkListBox.

This is a first step towards having GListModel support in Gtk. It's not
useful for large models, because GtkListBox always creates all widgets
for all rows.

GtkListBoxRow: Update the listbox's cursor row when focusing

https://bugzilla.gnome.org/show_bug.cgi?id=708320

file chooser: Allow opening folders in the file manager

This has been suggested in
https://bugzilla.gnome.org/show_bug.cgi?id=325150#c2

wayland: Implement minimize support

Use the existing xdg_surface API for minimization.

https://bugzilla.gnome.org/show_bug.cgi?id=695945

mir, gl: Ensure we use the 3.2 core profile

Emit an error if the profile is different.

mir: Switch GDK_GL_PROFILE_DEFAULT to mean 3_2_CORE

Instead of LEGACY.

mir, GL: Split GL context creation in two phases

Move egl_context initialization in gdk_gl_context_realize

 • gdk_window_create_gl_context() creates a GdkGLContext
 • gdk_gl_context_realize() creates the underlying resources

https://bugzilla.gnome.org/show_bug.cgi?id=741946

configure.ac: bump mirclient dependency to 0.11

Revert "image: Optimize non-resize changes"

This reverts commit 6276b9cda0b179e6a29b9002f82a338dc6f9649f.

This change was causing problems in gnome-mines. Revert it
until we can figure out what exactly is going wrong there.
See https://bugzilla.redhat.com/show_bug.cgi?id=1190887

Updated Norwegian bokmål translation.

Updated Norwegian bokmål translation.

Bump glib requirement

Needed for g_autoptr.

Bump version

stylecontext: Don't use cache when unsaved

Fixes image-load-from-file reftest

Updates

Fix annotations

The function gtk_label_set_attributes() is also used to
unset attributes, by passing %NULL. Reflect that in the
argument annotations.

gl: Fix the required version setter

We don't allow a version tuple to be lower than (3, 2), but we should
allow versions above that.

https://bugzilla.gnome.org/show_bug.cgi?id=744212

win32/gl: Ensure we use the 3.2 core profile

Emit an error if the profile is different.

This is a follow-up commit to commits cc45e82 (x11/gl: Ensure we use the
3.2 core profile) and 2d9081d (wayland/gl: Ensure we use the 3.2 core
profile), so that we do the same on GDK-Win32.  Update variable names and
comments so that the code is clearer to people, as we still need a
temporary legacy WGL context first before we can use
wglCreateContextAttribsARB() to create a WGL core (3.2+) context.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Put shaders in static storage

We are not changing the shader code.

The compiler will hopefully put them in the .rodata section.

gdkgl should use shader version 1.50

Using version 1.20 with a forward compatible 3.2 core context is incorrect
since OpenGL 3.2 deprecates shader version 1.20 (See section E.2). The latest
fglrx drivers will not compile these shaders.

https://bugzilla.gnome.org/show_bug.cgi?id=744203

Updated Lithuanian translation

demo: Change the resource path for the shaders

We need to use the same name as the "plugin" so that the main UI will
display the resources inside a notebook tab.

gl: Drop GdkGLContextClass.upload_texture()

It's unnecessary to allow per-backend overrides.

demo: Move the GLSL shaders to resources

It's easier to use them or modify them as separate files, instead of
inlined inside the C source.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Clean up the required version accessors

We can simplify the code, since we only have core GL profiles in GDK.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

docs: We do not support non-core GL profiles

No need to mention that some API only works on core GL profiles in the
GdkGLContext docs.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Clean up pre-requisite checks for GdkGLContext setters

We don't support non-core profiles.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

wayland/gl: Ensure we use the 3.2 core profile

Emit an error if the profile is different.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

x11/gl: Ensure we use the 3.2 core profile

Drop the dead code for the legacy profile, and return an error when
realizing if the profile is incorrect.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

demos: Update the GtkGLArea demo code

Same way we updated the testglarea test code.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

tests: Update testglarea

Since we dropped the legacy OpenGL compatibility profile, we need to use
recent OpenGL APi and concepts. This also means that the example code
gets a tad more complicated.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Add more debugging notes

https://bugzilla.gnome.org/show_bug.cgi?id=741946

glarea: Do not use extension API

We are using GL contexts with Core GL profiles, so we need to use the
proper API, not the one provided by extensions.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Do not use the extension API for core GL

Since we are using a Core GL profile, we need to drop the
extension-based API.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Drop OpenGL legacy profile

We simply don't want to care about legacy OpenGL.

All supported platforms also have support for OpenGL ≥ 3.2; it would
complicate the internal code; and would force us to use legacy GL
contexts internally if the first context created by the user is a legacy
GL context, and disable creation of core-3.2 contexts after that.

We will need to fix all our code examples to use the Core 3.2 profile.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Move getters for context options to the public API

They can be useful for third party code as well.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

Switch GDK_GL_PROFILE_DEFAULT to mean 3_2_CORE

Instead of LEGACY.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

win32/gl: Use the GdkGLContext options

https://bugzilla.gnome.org/show_bug.cgi?id=741946

GDK-Win32: Split GL context creation in two phases

Like what is being done in the X11 and Wayland backends, create the
GdkWin32GLContext in 2 steps, where we only create the actual WGL context
in _gdk_win32_gl_context_realize().

https://bugzilla.gnome.org/show_bug.cgi?id=741946

wayland/gl: Use the GdkGLContext options

https://bugzilla.gnome.org/show_bug.cgi?id=741946

x11/gl: Use the GdkGLContext options

When creating an OpenGL context using the glXCreateContextAttribs()
function.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

gl: Add context options

Users of the GdkGLContext API should be allowed to set properties on the
shim GdkGLContext instance prior to realization, so that the
backend-specific implementation can use the value of those properties
when creating the windowing system specific resources.

The main three options are:

 • a major/minor version tuple, to request a specific GL version
 • a debug bit, to request a "debug context", which provides additional
   validation and run time checking
 • a forward compatibility bit, to request a context that does not
   have deprecated functionality

See also:
 - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt

https://bugzilla.gnome.org/show_bug.cgi?id=741946

GL: Split GL context creation in two phases

One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.

We have a couple of requirements in terms of API:

 • avoid, if at all possible, the "C arrays of integers with
   attribute, value pairs", which are hard to write and hard
   to bind in non-C languages.
 • allow failing in a recoverable way.
 • do not make the GL context creation API a mess of arguments.

Looking at prior art, it seems that a common pattern is to split the
construction phase in two:

 • a first phase that creates a GL context wrapper object and
   does preliminary checks on the environment.
 • a second phase that creates the backend-specific GL object.

We adopted a similar pattern:

 • gdk_window_create_gl_context() creates a GdkGLContext
 • gdk_gl_context_realize() creates the underlying resources

Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.

https://bugzilla.gnome.org/show_bug.cgi?id=741946

Updated Russian translation

Updated Norwegian bokmål translation

Updated POTFILES.skip

css: Move scale to GtkStyleProviderPrivate

This way, we can remove it as a separate argument from
gtk_css_value_compute() and allow computation to only depend on one
thing: the style provider.

settings: Provide a default style cascade per scale

This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.

Style cascades are now nested like this:

GtkSettings root cascade (scale == 1)
 |
 +-- GtkSettings per scale cascade (for any scale, no custom providers)
 |
 +-- GtkStyleContext custom cascade (for any scale, custom providers)

This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.

The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.

stylecontext: Store the scale value in the cascade

This is in preparation for the next commits.

gdkglcontext-win32.h: Clean Up a Bit

We don't have a Win32-specific ->upload_texture() anymore, so don't
indicate so.  Left out this part from my previous commit.

GDK-Win32: Drop Win32-specific ->upload_texture()

The default ->upload_texture() works also for Windows since commit 27cf0fa,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa.  Clean up the GDK-Win32 code a
little bit as a result.

treeview: Fix copy/paste bug

Introduced in 7eecb16404b9fdcd1377e1a159f5e94f079e24b7

css: Add -gtk-dpi CSS property hack

This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.

And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
  -gtk-dpi: 48;
}
if you want to debug things.

Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.

treeview: Don't create an overly large pixel cache

GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.

Testcase included.

https://bugzilla.redhat.com/show_bug.cgi?id=1163579

blur: Simplify return_if_fail()

mir: release surface before rendering parent

We should remove the mir and cairo surface before rendering the
transient_for, which will regenerate the cairo surface anyways.
Otherwise, we end up releasing both, when we only really want to get rid
of the mir surface.

mir: don't always request mir surfaces

Some child window behaviour is faked by painting in the parent, so we
don't bother creating the Mir surface in that case.

mir: reconstruct surface if window is moved

mir: stop using deprecated surface api

mir: fix issues with mouse over parent menu

Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.

See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html

mir: add back window hierarchy functions

mir: stop forwarding motion events to subwindows

mir: generate leave events for transient children

mir: use monitor plug names more similar to the ones used in Xmir

mir: only paint background if window has one

mir: use old scrolling system if we get simple integer values

mir: end the current grab on ungrab

mir: only render non-top-level transients.

mir: handle new MirCloseSurfaceEvent

mir: reset cursor_inside on hide/withdraw

Without this, we generate incorrect crossing events for transient
windows.

mir: disable some debug output

mir: skip windows that aren't visible

mir: fix IsModifierKey definition

mir: check the log events env variable just once

mir: set event source device as well

mir: fix time conversion macro

mir: implement stub _gdk_mir_keymap_key_is_modifier

Using IsModifierKey for now

mir: check (using simple keycode checking) if we're handling a modifier key

mir: compute the modifiers using the saved button_state on key events

mir: add a NANO_TO_MILLI conversion macro

mir: properly converts mir nanoseconds timestamps to milliseconds

mir: use actual events time

mir: add timestamps to generated GdkEvents

We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.

mir: pass motion events down to transient children

mir: use parent_window's impl for GDK_INPUT_ONLY windows

Fixes a crash that occurs when the user selects text.

scrolledwindow: Don't hover the scrollbars while a button is being pressed

This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=743894

popover: Unset the grab when the popover loses its parent

This ensures the grab and signal handlers are removed if the parent goes
NULL.

window: Unparent popover before unmapping/unrealizing

Otherwise spurious invariants warnings may happen before the popover
is removed from the window.

window: call gtk_widget_unmap() on popover widgets unconditionally

is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.

popover: Keep a ref on the parent scrollable

This ensures the scrollable is still alive on dispose(), and properly unset
after disconnecting all signal handlers.

GtkStatusIcon: Expand deprecation docs

https://bugzilla.gnome.org/show_bug.cgi?id=743975

stylecontext: Don't crah when invalidate() is called on saved context

We need to invalidate the root node, not the current one.
Fixes crashes on startup of eclipse.

Testcase included.

https://bugzilla.redhat.com/show_bug.cgi?id=1185828

stylecontext: Do not have a default style

A bunch of applications expect the style to be as close to the actual
style as possible even during creation of the widget. Try to accomodate
these apps.

This reverses the effects of 27285f1f0fb00bb4507a8bf3e426bef940ae41af

https://bugzilla.gnome.org/show_bug.cgi?id=743395
https://bugzilla.redhat.com/show_bug.cgi?id=1185999

css: Having a static style per screen isn't useful

Just have one static style for everything.